A Massachusetts Institute of Technology (MIT) proposal for a data format for storing self-descriptive data in a RF ID tag and serially reading self-descriptive data from such a data tag has been disclosed in http://auto-id.mit.edu/pdf/MIT-AUTOID-WH-001.pdf, December 2000, which has been retrieved from the WWW at Mar. 7, 2001. The way data is stored in and read from data tags with limited storage capacity, like radio frequency identification (RF ID) tags, smart cards and similar devices, is highly relevant both in terms of standardization of allowed data formats, as well as in terms of the compactness of the data stored in such tags due to the low-cost demand for such devices. The latter for instance applies to RF ID tags, especially in application areas where the tags are to compete with other low-cost identification means, e.g. bar codes. An obvious advantage of using RF ID tags in product labeling is that they can be read out from relatively large distances with high reliability, in contrast with bar codes that have to be read out in line-of-sight with the bar code reader, which is much more error-sensitive. A drawback, however, is that RF ID tags are more costly than bar codes. Therefore, maximizing the utilization of the storage capacity of a RF ID tag is a very important issue. The proposed MIT standard, the so-called electronic Product Code (ePC), embodies a 96-bit data format developed for read-only tags. The 96 bits are segmented in a 8-bit header and three data elements, each with fixed lengths. The header can contain metadata indicating the format, total length or various fixed-length field partitions of the RF ID tag, which ensures flexibility of the standard for enabling the future use of larger sized fixed-length tags. In the ePC, the first two data elements, or data partitions, are assigned to a 24-bit manufacturer code and 24-bit product code, whereas the final 40-bit element is assigned to the product serial number.
A major drawback of such a standard, however, is that the assignment of the segment dimensions is based on worst-case scenarios, i.e. the dimensions have been chosen such that they facilitate the storage of excessivily large numbers. Although this can be a guarantee for long-term application of the standard within markets with expanding sales volumes, in practice, it also implies that in many cases a significant number of bits in the tag are redundant. This is an unwanted side effect of a fixed length format in terms of tag cost price.
Another major disadvantage is that the flexibility of information stored in the tag is restricted by pre-assigning the three segments. It is foreseen that for certain product domains, other information can be highly relevant. As an example, a data tag attached to an audio compact disk (CD) enclosure could encode the CD's publisher in field type #1, the name of the main artist in field type #2, a code for the title in field type #3, and the data of publication in field type #6. As an alternative example, a data tag attached to an item being shipped via a parcel delivery service could contain fields containing the shipment's identification, priority, submission time, and final destination. As a final example, a data tag worn by an employee could contain fields with the employee's identification number, the employee's name, a security clearance class, the expiration date of the data carrier and a digital photograph of the employee.
In such cases, the three pre-assigned data fields are of limited use, or the fixed 96-bit length of the tag might not suffice to store all relevant information in the tag.